Errors using psqlodbc

--_000_6B48F83ECA0ABA4F9E360E8E0A1CDFFC35E4AE0EHALLEYmaeilpt _
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi there ,
I'm using psqlodbc version 9.00.01.01 UNICODE , in Windows Server 2003.
Have created a new data source and activated the logs.
In the psqlodbc logs I get the following error messages:

[0.002]conn=3D026B40E0, PGAPI_DriverConnect( in)=3D'DSN=3DPostgresTeste;', =
fDriverCompletion=3D1
[0.011]DSN info: DSN=3D'PostgresTeste',server=3D'libra',port=3D'5432',dbase=
=3D'mtransteste',user=3D'minimal',passwd=3D'xxxxx'
[0.021] onlyread=3D'0',protocol=3D'7.4',showoid=3D'0',fakeoidindex=
=3D'0',showsystable=3D'0'
[0.028] conn_settings=3D'', conn_encoding=3D'(null)'
[0.032] translation_dll=3D'',translation_option=3D''
[0.053]Driver Version=3D'09.00.0101,201010160001' linking 1500 static Multi=
thread library
[0.074]Global Options: fetch=3D100, socket=3D4096, unknown_sizes=3D0, max_v=
archar_size=3D255, max_longvarchar_size=3D8190
[0.099] disable_optimizer=3D0, ksqo=3D1, unique_index=3D1, u=
se_declarefetch=3D1
[0.106] text_as_longvarchar=3D1, unknowns_as_longvarchar=3D0=
, bools_as_char=3D1 NAMEDATALEN=3D64
[0.113] extra_systable_prefixes=3D'dd_;', conn_settings=3D''=
conn_encoding=3D''
[0.250] [ PostgreSQL version string =3D '8.4.4' ]
[0.252] [ PostgreSQL version number =3D '8.4' ]
[0.316]conn=3D026B40E0, query=3D'select oid, typbasetype from pg_type where=
typname =3D 'lo''
[0.377] [ fetched 0 rows ]
[0.417] [ Large Object oid =3D -999 ]
[0.422] [ Client encoding =3D 'UTF8' (code =3D 6) ]
[0.443]conn=3D026B40E0, PGAPI_DriverConnect(out)=3D'DSN=3DPostgresTeste;DAT=
ABASE=3Dmtransteste;SERVER=3Dlibra;PORT=3D5432;UID=3Dminimal ;PWD=3Dxxxxxxx;=
CA=3Dd;A6=3D;A7=3D100;A8=3D4096;B0=3D255;B1=3D8190;BI=3D0;C2 =3Ddd_;;CX=3D1c=
54ebb;A1=3D7.4-1'
[6.044]CONN ERROR: func=3Dset_statement_option, desc=3D'', errnum=3D-1, err=
msg=3D'Requested value changed.'
[6.057] --------------------------------------------------------=
----
[6.062] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=
=3D16
[6.067] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
[6.071] ---------------- Socket Info ---------------------------=
----
[6.075] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'=
(NULL)'
[6.080] buffer_in=3D40594504, buffer_out=3D40598608
[6.083] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_rea=
d_in=3D77
[6.090]CONN ERROR: func=3DPGAPI_SetConnectOption, desc=3D'', errnum=3D-1, e=
rrmsg=3D'Requested value changed.'
[6.104] --------------------------------------------------------=
----
[6.108] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=
=3D16
[6.112] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
[6.115] ---------------- Socket Info ---------------------------=
----
[6.120] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'=
(NULL)'
[6.125] buffer_in=3D40594504, buffer_out=3D40598608
[6.128] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_rea=
d_in=3D77
[6.160]CONN ERROR: func=3Dset_statement_option, desc=3D'', errnum=3D-1, err=
msg=3D'Requested value changed.'
[6.172] --------------------------------------------------------=
----
[6.177] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=
=3D16
[6.181] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
[6.186] ---------------- Socket Info ---------------------------=
----
[6.191] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'=
(NULL)'
[6.195] buffer_in=3D40594504, buffer_out=3D40598608
[6.199] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_rea=
d_in=3D77
[6.207]CONN ERROR: func=3DPGAPI_SetConnectOption, desc=3D'', errnum=3D-1, e=
rrmsg=3D'Requested value changed.'
[6.218] --------------------------------------------------------=
----
[6.222] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=
=3D16
[6.226] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
[6.232] ---------------- Socket Info ---------------------------=
----
[6.237] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'=
(NULL)'
[6.242] buffer_in=3D40594504, buffer_out=3D40598608
[6.246] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_rea=
d_in=3D77


I get those 4 CONN ERROR and can't find anything related to them

Any help?

Os melhores cumprimentos,
Nelson Andr=E9
Senior Software Engineer
Maeil Consultores - Tecnologias de Integração de Empresas, Lda.
http://www.maeil.pt http://helpdesk.maeil.pt //helpdesk.maeil.pt/>



AVISO DE CONFIDENCIALIDADE
Esta mensagem de correio electr=F3nico e qualquer dos seus ficheiros anexos=
, caso existam, s=E3o confidenciais e destinados apenas =E0(s) pessoa(s) ou=
entidade(s) acima referida(s), podendo conter informação confidencial,=
privilegiada, a qual n=E3o dever=E1 ser divulgada, copiada, gravada ou dis=
tribu=EDda nos termos da lei vigente. Se n=E3o =E9 o destinat=E1rio da mens=
agem, ou se ela lhe foi enviada por engano, agradecemos que n=E3o fa=E7a us=
o ou divulgação da mesma. A distribuição ou utilização da infor=
mação nela contida =E9 VEDADA. Se recebeu esta mensagem por engano, por=
favor avise-nos de imediato, por correio electr=F3nico, para o endere=E7o =
acima e apague este e-mail do seu sistema. Obrigado.
CONFIDENTIALITY NOTICE
This e-mail transmission and eventual attached files are intended only for =
the use of the individual or entity named above and may contain information=
that is confidential, privileged and exempt from disclosure under applicab=
le law. If you are not the intended recipient, you are hereby notified that=
any disclosure, copying, distribution or use of any of the information con=
tained in this transmission is strictly VOIDED. If you have received this t=
ransmission in error, please immediately notify us by e-mail at the above a=
ddress and delete this e-mail from your system. Thank you.

--_000_6B48F83ECA0ABA4F9E360E8E0A1CDFFC35E4AE0EHALLEYmaeilpt _
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

1">

Re: Errors using psqlodbc

(2010/11/03 1:46), Nelson Andre wrote:
> Hi there ,
>
> I=92m using psqlodbc version 9.00.01.01 UNICODE , in Windows Server 200=
3.
>
> Have created a new data source and activated the logs.
>
> In the psqlodbc logs I get the following error messages:
>
> [0.002]conn=3D026B40E0, PGAPI_DriverConnect( in)=3D'DSN=3DPostgresTeste=
;',
> fDriverCompletion=3D1
>
> [0.011]DSN info:
> DSN=3D'PostgresTeste',server=3D'libra',port=3D'5432',dbase=3 D'mtranstes=
te',user=3D'minimal',passwd=3D'xxxxx'
>
> [0.021]
> onlyread=3D'0',protocol=3D'7.4',showoid=3D'0',fakeoidindex=3 D'0',showsy=
stable=3D'0'
>
> [0.028] conn_settings=3D'', conn_encoding=3D'(null)'
>
> [0.032] translation_dll=3D'',translation_option=3D''
>
> [0.053]Driver Version=3D'09.00.0101,201010160001' linking 1500 static
> Multithread library
>
> [0.074]Global Options: fetch=3D100, socket=3D4096, unknown_sizes=3D0,
> max_varchar_size=3D255, max_longvarchar_size=3D8190
>
> [0.099] disable_optimizer=3D0, ksqo=3D1, unique_index=3D1, use_declaref=
etch=3D1
>
> [0.106] text_as_longvarchar=3D1, unknowns_as_longvarchar=3D0,
> bools_as_char=3D1 NAMEDATALEN=3D64
>
> [0.113] extra_systable_prefixes=3D'dd_;', conn_settings=3D'' conn_encod=
ing=3D''
>
> [0.250] [ PostgreSQL version string =3D '8.4.4' ]
>
> [0.252] [ PostgreSQL version number =3D '8.4' ]
>
> [0.316]conn=3D026B40E0, query=3D'select oid, typbasetype from pg_type w=
here
> typname =3D 'lo''
>
> [0.377] [ fetched 0 rows ]
>
> [0.417] [ Large Object oid =3D -999 ]
>
> [0.422] [ Client encoding =3D 'UTF8' (code =3D 6) ]
>
> [0.443]conn=3D026B40E0,
> PGAPI_DriverConnect(out)=3D'DSN=3DPostgresTeste;DATABASE=3Dm transteste;=
SERVER=3Dlibra;PORT=3D5432;UID=3Dminimal;PWD=3Dxxxxxxx;CA=3D d;A6=3D;A7=3D=
100;A8=3D4096;B0=3D255;B1=3D8190;BI=3D0;C2=3Ddd_;;CX=3D1c54e bb;A1=3D7.4-1=
'
>
> [6.044]CONN ERROR: func=3Dset_statement_option, desc=3D'', errnum=3D-1,
> errmsg=3D'Requested value changed.'
>
> [6.057] ------------------------------------------------------------
>
> [6.062] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=3D16
>
> [6.067] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
>
> [6.071] ---------------- Socket Info -------------------------------
>
> [6.075] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'(NULL)'
>
> [6.080] buffer_in=3D40594504, buffer_out=3D40598608
>
> [6.083] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_read_in=3D=
77
>
> [6.090]CONN ERROR: func=3DPGAPI_SetConnectOption, desc=3D'', errnum=3D-=
1,
> errmsg=3D'Requested value changed.'
>
> [6.104] ------------------------------------------------------------
>
> [6.108] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=3D16
>
> [6.112] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
>
> [6.115] ---------------- Socket Info -------------------------------
>
> [6.120] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'(NULL)'
>
> [6.125] buffer_in=3D40594504, buffer_out=3D40598608
>
> [6.128] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_read_in=3D=
77
>
> [6.160]CONN ERROR: func=3Dset_statement_option, desc=3D'', errnum=3D-1,
> errmsg=3D'Requested value changed.'
>
> [6.172] ------------------------------------------------------------
>
> [6.177] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=3D16
>
> [6.181] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
>
> [6.186] ---------------- Socket Info -------------------------------
>
> [6.191] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'(NULL)'
>
> [6.195] buffer_in=3D40594504, buffer_out=3D40598608
>
> [6.199] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_read_in=3D=
77
>
> [6.207]CONN ERROR: func=3DPGAPI_SetConnectOption, desc=3D'', errnum=3D-=
1,
> errmsg=3D'Requested value changed.'
>
> [6.218] ------------------------------------------------------------
>
> [6.222] henv=3D026B2150, conn=3D026B40E0, status=3D1, num_stmts=3D16
>
> [6.226] sock=3D026B2180, stmts=3D026B2250, lobj_type=3D-999
>
> [6.232] ---------------- Socket Info -------------------------------
>
> [6.237] socket=3D612, reverse=3D0, errornumber=3D0, errormsg=3D'(NULL)'
>
> [6.242] buffer_in=3D40594504, buffer_out=3D40598608
>
> [6.246] buffer_filled_in=3D77, buffer_filled_out=3D0, buffer_read_in=3D=
77
>
> I get those 4 CONN ERROR and can=92t find anything related to them
>
> Any help?

Those messages are warnings not errors.

regards,
Hiroshi Inoue


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Various errors in psqlodbc: SQLGetTypeInfo, SQLTables, bigint, anddouble vs float

Hi all,

apologies if this is already in the bug tracker (I had a look but didn't
find it).

We recently did some work to get our product working with PostgreSQL 9.0
and the latest ODBC driver. Our code is written to (try to) be
DBMS-agnostic. So it enumerates reported types, searches for matching
types etc, and builds CREATE TABLE statements etc from what it finds.

There were a couple of inconsistencies in data returned from the ODBC
driver.

1. Data returned from SQLGetTypeInfo uses ODBC2 field names.

The columns reported include

"PRECISION" instead of "COLUMN_SIZE"
"MONEY" instead of "FIXED_PREC_SCALE"
"AUTO_INCREMENT" instead of "AUTO_UNIQUE_VALUE"

2. Data returned from SQLTables uses ODBC2 field names

"TABLE_QUALIFIER" instead of "TABLE_CAT"
"TABLE_OWNER" instead of "TABLE_SCHEM"

These 2 issues aren't huge problems, since the ordinal column number
stays the same.

3. Not all supported types returned by SQLGetTypeInfo

Specifically the types SERIAL and BIGSERIAL are not reported. This
means we needed to hard-code a hack so if the driver was PostgreSQL and
we needed an AUTO_UNIQUE_VALUE counter, we used "SERIAL". It works, but
if SQLGetTypeInfo returned these types, it wouldn't need the hack.

4. Oddness with bigint fields.

bigint reported as precision of 19, instead of 20. This isn't big
enough to store an unsigned __int64

5. Oddness with double precision fields.

We had to use double precision fields to store file size information,
because bigint couldn't do an __int64 (not sure what actual C type this
really maps to in reality). However when we get the field data back in
a query, it is reported as type SQL_FLOAT, even though the DB structure
in the PostgreSQL manager shows it as double precision. Obviously you
don't want to truncate double to float, so is this just in the driver
(some type switch case not supported?)

Once we worked around all these issues, it seems to be working great.
I'm a bit concerned about losing precision with double vs float though.

Regards

Adrien

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Various errors in psqlodbc: SQLGetTypeInfo, SQLTables,bigint, and double vs float

Hi,

(2010/11/03 12:22), Adrien de Croy wrote:
>
> Hi all,
>
> apologies if this is already in the bug tracker (I had a look but didn't
> find it).
>
> We recently did some work to get our product working with PostgreSQL 9.0
> and the latest ODBC driver. Our code is written to (try to) be
> DBMS-agnostic. So it enumerates reported types, searches for matching
> types etc, and builds CREATE TABLE statements etc from what it finds.
>
> There were a couple of inconsistencies in data returned from the ODBC
> driver.
>
> 1. Data returned from SQLGetTypeInfo uses ODBC2 field names.
>
> The columns reported include
>
> "PRECISION" instead of "COLUMN_SIZE"
> "MONEY" instead of "FIXED_PREC_SCALE"
> "AUTO_INCREMENT" instead of "AUTO_UNIQUE_VALUE"
>
> 2. Data returned from SQLTables uses ODBC2 field names
>
> "TABLE_QUALIFIER" instead of "TABLE_CAT"
> "TABLE_OWNER" instead of "TABLE_SCHEM"
>
> These 2 issues aren't huge problems, since the ordinal column number
> stays the same.
>
> 3. Not all supported types returned by SQLGetTypeInfo
>
> Specifically the types SERIAL and BIGSERIAL are not reported. This means
> we needed to hard-code a hack so if the driver was PostgreSQL and we
> needed an AUTO_UNIQUE_VALUE counter, we used "SERIAL". It works, but if
> SQLGetTypeInfo returned these types, it wouldn't need the hack.
>
> 4. Oddness with bigint fields.
>
> bigint reported as precision of 19, instead of 20. This isn't big enough
> to store an unsigned __int64

Because int8 type in PostgreSQL is signed, the precision is 19.

> 5. Oddness with double precision fields.
>
> We had to use double precision fields to store file size information,
> because bigint couldn't do an __int64 (not sure what actual C type this
> really maps to in reality). However when we get the field data back in a
> query, it is reported as type SQL_FLOAT, even though the DB structure in
> the PostgreSQL manager shows it as double precision. Obviously you don't
> want to truncate double to float, so is this just in the driver (some
> type switch case not supported?)

SQL_FLOAT means double precision type. What means signle precision type
is SQL_REAL.

> Once we worked around all these issues, it seems to be working great.
> I'm a bit concerned about losing precision with double vs float though.
>
> Regards
>
> Adrien


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Various errors in psqlodbc: SQLGetTypeInfo, SQLTables,bigint, and double vs float

Hi

On 3/11/2010 9:36 p.m., Hiroshi Inoue wrote:
> Hi,
>
> (2010/11/03 12:22), Adrien de Croy wrote: 5. Oddness with double
> precision fields.
>>
>> We had to use double precision fields to store file size information,
>> because bigint couldn't do an __int64 (not sure what actual C type this
>> really maps to in reality). However when we get the field data back in a
>> query, it is reported as type SQL_FLOAT, even though the DB structure in
>> the PostgreSQL manager shows it as double precision. Obviously you don't
>> want to truncate double to float, so is this just in the driver (some
>> type switch case not supported?)
>
> SQL_FLOAT means double precision type. What means signle precision type
> is SQL_REAL.

When I tried to store a C double type (8byte floating point) into this
field which reported itself as SQL_FLOAT even though it's "double
precision", it reported that the thing I was poking in was too big, so I
had to fall back to storing it as a C float type. This is using
SQLBindParameter.

my understanding is SQL_DOUBLE is required. Is that used? It's
certainly used by other DBs, such as MySQL, MS SQL server and Access even.

Thanks for your reply

Regards

Adrien

>
>> Once we worked around all these issues, it seems to be working great.
>> I'm a bit concerned about losing precision with double vs float though.
>>
>> Regards
>>
>> Adrien
>

--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Various errors in psqlodbc: SQLGetTypeInfo, SQLTables,bigint, and double vs float

Hi again

apologies, I did some more research. Looks like SQL_FLOAT and
SQL_DOUBLE are used for c double types, and SQL_REAL for c float type.

very confusing, but that's not unusual for ODBC.

So I've also managed to solve my bigint issue, by falling back to a
signed __int64 instead of unsigned. I guess there's no plan to
implement unsigned numeric types?

Adrien


On 3/11/2010 9:36 p.m., Hiroshi Inoue wrote:
> Hi,
>
> (2010/11/03 12:22), Adrien de Croy wrote:
>>
>> Hi all,
>>
>> apologies if this is already in the bug tracker (I had a look but didn't
>> find it).
>>
>> We recently did some work to get our product working with PostgreSQL 9.0
>> and the latest ODBC driver. Our code is written to (try to) be
>> DBMS-agnostic. So it enumerates reported types, searches for matching
>> types etc, and builds CREATE TABLE statements etc from what it finds.
>>
>> There were a couple of inconsistencies in data returned from the ODBC
>> driver.
>>
>> 1. Data returned from SQLGetTypeInfo uses ODBC2 field names.
>>
>> The columns reported include
>>
>> "PRECISION" instead of "COLUMN_SIZE"
>> "MONEY" instead of "FIXED_PREC_SCALE"
>> "AUTO_INCREMENT" instead of "AUTO_UNIQUE_VALUE"
>>
>> 2. Data returned from SQLTables uses ODBC2 field names
>>
>> "TABLE_QUALIFIER" instead of "TABLE_CAT"
>> "TABLE_OWNER" instead of "TABLE_SCHEM"
>>
>> These 2 issues aren't huge problems, since the ordinal column number
>> stays the same.
>>
>> 3. Not all supported types returned by SQLGetTypeInfo
>>
>> Specifically the types SERIAL and BIGSERIAL are not reported. This means
>> we needed to hard-code a hack so if the driver was PostgreSQL and we
>> needed an AUTO_UNIQUE_VALUE counter, we used "SERIAL". It works, but if
>> SQLGetTypeInfo returned these types, it wouldn't need the hack.
>>
>> 4. Oddness with bigint fields.
>>
>> bigint reported as precision of 19, instead of 20. This isn't big enough
>> to store an unsigned __int64
>
> Because int8 type in PostgreSQL is signed, the precision is 19.
>
>> 5. Oddness with double precision fields.
>>
>> We had to use double precision fields to store file size information,
>> because bigint couldn't do an __int64 (not sure what actual C type this
>> really maps to in reality). However when we get the field data back in a
>> query, it is reported as type SQL_FLOAT, even though the DB structure in
>> the PostgreSQL manager shows it as double precision. Obviously you don't
>> want to truncate double to float, so is this just in the driver (some
>> type switch case not supported?)
>
> SQL_FLOAT means double precision type. What means signle precision type
> is SQL_REAL.
>
>> Once we worked around all these issues, it seems to be working great.
>> I'm a bit concerned about losing precision with double vs float though.
>>
>> Regards
>>
>> Adrien
>
>

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Errors using psqlodbc

Hi Hiroshi,

The log keeps repeting some part of the text until I kill the application b=
ecause it hangs and consumes 90+ % of the CPU.
I will try the drivers you referred and then let you know.

Thanks.

Os melhores cumprimentos,
Nelson Andr=E9
Senior Software Engineer
Maeil Consultores - Tecnologias de Integração de Empresas, Lda.
P: (+351) 214 229 117 F: (+351) 214 229 119
http://www.maeil.pt   =A0http://helpdesk.maeil.pt


-----Original Message-----
From: Hiroshi Inoue [mailto:inoue@tpf.co.jp]=20
Sent: quinta-feira, 4 de Novembro de 2010 08:37
To: Nelson Andre
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Errors using psqlodbc

Hi Nelson,

(2010/11/03 19:05), Nelson Andre wrote:
> When I run my application , it hangs and I have to kill it in Task Manage=
r.
>
> This is the content of mylog_5856.txt



> [5860-7.715]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' '=
, token=3D'(', ptr=3D'PGcA =3D ? ) ORDER BY PGcA '
> [5860-7.723]blevel++ -> 1
> [5860-7.724]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' '=
, token=3D'PGcA', ptr=3D'=3D ? ) ORDER BY PGcA '
> [5860-7.731]got ispunct: s[0] =3D '=3D'
> [5860-7.733]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' '=
, token=3D'=3D', ptr=3D'? ) ORDER BY PGcA '
> [5860-7.740]got ispunct: s[0] =3D '?'
> [5860-7.744]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' '=
, token=3D'?', ptr=3D') ORDER BY PGcA '
> [5860-7.752]got ispunct: s[0] =3D ')'
> [5860-7.753]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' '=
, token=3D')', ptr=3D'ORDER BY PGcA '
> [5860-7.760]blevel-- =3D 0
> [5860-7.762]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' '=
, token=3D'ORDER', ptr=3D'BY PGcA '
> [5860-7.767]ORDER...
> [5860-7.769]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' '=
, token=3D'BY', ptr=3D'PGcA '
> [5860-7.774]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D'

Does the log stop here?
If so, could you please try the drivers on testing for 9.0.0201 at
http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
?

regards,
Hiroshi Inoue


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW

Hi all

I'm getting an access violation from within SQLDescribeColW when I'm
getting the result scheme from a query.

the query is pretty simple:

SELECT count(*) as folder_files, sum(file_size) as folder_size,
sum(disk_use) as folder_size_disk, folder_id from cache_index where
volume_id = %u group by folder_id

SQLExecute returns OK
SQLNumResultCols returns 4 columns as expected

the SQLDescribeColW blows up when calling with column #2, corresponding
to sum(file_size). file_size is a bigint field. There are only 5
records, and the sum of the file_size is under 1MB. So shouldn't be any
bigint overflow or something.

I used to use a double precision and it worked fine, then I figured out
how to store into a bigint field and now this happens every time I do
this query if there are any records in the table. If there are no
records it's fine.

Regards

Adrien de Croy

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL whencalling SQLDescribeColW

Hiã€=81

(2010/11/05 7:44), Adrien de Croy wrote:
>
> Hi all
>
> I'm getting an access violation from within SQLDescribeColW when I'm
> getting the result scheme from a query.

Hmm I may have introduced a bug in 9.0.0200.

Could you please try the drivers on testing for 9.0.0201 at
http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
?

regards,
Hiroshi Inoue

> the query is pretty simple:
>
> SELECT count(*) as folder_files, sum(file_size) as folder_size,
> sum(disk_use) as folder_size_disk, folder_id from cache_index where
> volume_id =3D %u group by folder_id
>
> SQLExecute returns OK
> SQLNumResultCols returns 4 columns as expected
>
> the SQLDescribeColW blows up when calling with column #2, corresponding
> to sum(file_size). file_size is a bigint field. There are only 5
> records, and the sum of the file_size is under 1MB. So shouldn't be any
> bigint overflow or something.
>
> I used to use a double precision and it worked fine, then I figured out
> how to store into a bigint field and now this happens every time I do
> this query if there are any records in the table. If there are no
> records it's fine.
>
> Regards
>
> Adrien de Croy


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL whencalling SQLDescribeColW

Hi Hiroshi

this build has another problem

::SQLTables no longer returns the table name at all (empty string).

So I can't test any further, since I require this for all my startup=20
code, type retrieval etc (for a column of a table def).

Regards

Adrien


On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
> Hiã€=81
>
> (2010/11/05 7:44), Adrien de Croy wrote:
>>
>> Hi all
>>
>> I'm getting an access violation from within SQLDescribeColW when I'm
>> getting the result scheme from a query.
>
> Hmm I may have introduced a bug in 9.0.0200.
>
> Could you please try the drivers on testing for 9.0.0201 at
> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
> ?
>
> regards,
> Hiroshi Inoue
>
>> the query is pretty simple:
>>
>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>> volume_id =3D %u group by folder_id
>>
>> SQLExecute returns OK
>> SQLNumResultCols returns 4 columns as expected
>>
>> the SQLDescribeColW blows up when calling with column #2, correspondin=
g
>> to sum(file_size). file_size is a bigint field. There are only 5
>> records, and the sum of the file_size is under 1MB. So shouldn't be an=
y
>> bigint overflow or something.
>>
>> I used to use a double precision and it worked fine, then I figured ou=
t
>> how to store into a bigint field and now this happens every time I do
>> this query if there are any records in the table. If there are no
>> records it's fine.
>>
>> Regards
>>
>> Adrien de Croy
>
>

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL whencalling SQLDescribeColW

also seems to break the table scheme. This one isn't important to me,=20
but maybe to others.

One other thing I found, even on the 9.00.0200 build.

Once you fetch data on a field in a record, if you try to fetch the same=20
field on the same row again (without moving cursor or anything) it blows=20
up also. fetching seems to alter what you fetch.

Regards

Adrien


On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
> Hiã€=81
>
> (2010/11/05 7:44), Adrien de Croy wrote:
>>
>> Hi all
>>
>> I'm getting an access violation from within SQLDescribeColW when I'm
>> getting the result scheme from a query.
>
> Hmm I may have introduced a bug in 9.0.0200.
>
> Could you please try the drivers on testing for 9.0.0201 at
> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
> ?
>
> regards,
> Hiroshi Inoue
>
>> the query is pretty simple:
>>
>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>> volume_id =3D %u group by folder_id
>>
>> SQLExecute returns OK
>> SQLNumResultCols returns 4 columns as expected
>>
>> the SQLDescribeColW blows up when calling with column #2, correspondin=
g
>> to sum(file_size). file_size is a bigint field. There are only 5
>> records, and the sum of the file_size is under 1MB. So shouldn't be an=
y
>> bigint overflow or something.
>>
>> I used to use a double precision and it worked fine, then I figured ou=
t
>> how to store into a bigint field and now this happens every time I do
>> this query if there are any records in the table. If there are no
>> records it's fine.
>>
>> Regards
>>
>> Adrien de Croy
>
>

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL whencalling SQLDescribeColW

(2010/11/10 10:40), Adrien de Croy wrote:
>
> Hi Hiroshi
>
> this build has another problem
>
> ::SQLTables no longer returns the table name at all (empty string).

Oops, I seem to have introduced another bug so as to fix
[ODBC] Errors using psqlodbc .
I would fix it and report soon.

regards,
Hiroshi Inoue

> So I can't test any further, since I require this for all my startup
> code, type retrieval etc (for a column of a table def).
>
> Regards
>
> Adrien
>
>
> On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
>> Hiã€=81
>>
>> (2010/11/05 7:44), Adrien de Croy wrote:
>>>
>>> Hi all
>>>
>>> I'm getting an access violation from within SQLDescribeColW when I'm
>>> getting the result scheme from a query.
>>
>> Hmm I may have introduced a bug in 9.0.0200.
>>
>> Could you please try the drivers on testing for 9.0.0201 at
>> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
>> ?
>>
>> regards,
>> Hiroshi Inoue
>>
>>> the query is pretty simple:
>>>
>>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>>> volume_id =3D %u group by folder_id
>>>
>>> SQLExecute returns OK
>>> SQLNumResultCols returns 4 columns as expected
>>>
>>> the SQLDescribeColW blows up when calling with column #2, correspondi=
ng
>>> to sum(file_size). file_size is a bigint field. There are only 5
>>> records, and the sum of the file_size is under 1MB. So shouldn't be a=
ny
>>> bigint overflow or something.
>>>
>>> I used to use a double precision and it worked fine, then I figured o=
ut
>>> how to store into a bigint field and now this happens every time I do
>>> this query if there are any records in the table. If there are no
>>> records it's fine.
>>>
>>> Regards
>>>
>>> Adrien de Croy


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL whencalling SQLDescribeColW

Hi Adrien,

(2010/11/10 10:48), Adrien de Croy wrote:
>
> also seems to break the table scheme. This one isn't important to me,
> but maybe to others.
>
> One other thing I found, even on the 9.00.0200 build.
>
> Once you fetch data on a field in a record, if you try to fetch the sam=
e
> field on the same row again (without moving cursor or anything) it blow=
s
> up also. fetching seems to alter what you fetch.

What do you mean by *fetch(again)*?

regards,
Hiroshi Inoue

>
> On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
>> Hiã€=81
>>
>> (2010/11/05 7:44), Adrien de Croy wrote:
>>>
>>> Hi all
>>>
>>> I'm getting an access violation from within SQLDescribeColW when I'm
>>> getting the result scheme from a query.
>>
>> Hmm I may have introduced a bug in 9.0.0200.
>>
>> Could you please try the drivers on testing for 9.0.0201 at
>> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
>> ?
>>
>> regards,
>> Hiroshi Inoue
>>
>>> the query is pretty simple:
>>>
>>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>>> volume_id =3D %u group by folder_id
>>>
>>> SQLExecute returns OK
>>> SQLNumResultCols returns 4 columns as expected
>>>
>>> the SQLDescribeColW blows up when calling with column #2, correspondi=
ng
>>> to sum(file_size). file_size is a bigint field. There are only 5
>>> records, and the sum of the file_size is under 1MB. So shouldn't be a=
ny
>>> bigint overflow or something.
>>>
>>> I used to use a double precision and it worked fine, then I figured o=
ut
>>> how to store into a bigint field and now this happens every time I do
>>> this query if there are any records in the table. If there are no
>>> records it's fine.
>>>
>>> Regards
>>>
>>> Adrien de Croy
>>
>>
>
>
>
>



--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL whencalling SQLDescribeColW

Hi

I have some helper classes to fetch fields from a record, a helper class=20
to manage iteration through a result set.

If I call my fetch helper function for some field ordinal it works fine=20
the first time. If I call it again (without having called any method to=20
change the current row in the result set) it fails on the same ordinal,=20
but works on other ordinals.

So, it looks to me like the fetch call is cleaning up the field data=20
when you fetch, rather than cleaning up the row when you say move to the=20
next row.

I don't know if this is a bug or not - for instance MS SQL server fails=20
if you fetch columns in a non-monitonically-increasing column ordinal=20
order. E.g. fetch columns 1, 2, 3 works but not 1, 3, 2. So maybe ODBC=20
doesn't guarantee it's safe to call fetch columns 1, 1, x

Adrien




On 10/11/2010 4:52 p.m., Hiroshi Inoue wrote:
> Hi Adrien,
>
> (2010/11/10 10:48), Adrien de Croy wrote:
>>
>> also seems to break the table scheme. This one isn't important to me,
>> but maybe to others.
>>
>> One other thing I found, even on the 9.00.0200 build.
>>
>> Once you fetch data on a field in a record, if you try to fetch the sa=
me
>> field on the same row again (without moving cursor or anything) it blo=
ws
>> up also. fetching seems to alter what you fetch.
>
> What do you mean by *fetch(again)*?
>
> regards,
> Hiroshi Inoue
>
>>
>> On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
>>> Hiã€=81
>>>
>>> (2010/11/05 7:44), Adrien de Croy wrote:
>>>>
>>>> Hi all
>>>>
>>>> I'm getting an access violation from within SQLDescribeColW when I'm
>>>> getting the result scheme from a query.
>>>
>>> Hmm I may have introduced a bug in 9.0.0200.
>>>
>>> Could you please try the drivers on testing for 9.0.0201 at
>>> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
>>> ?
>>>
>>> regards,
>>> Hiroshi Inoue
>>>
>>>> the query is pretty simple:
>>>>
>>>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>>>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>>>> volume_id =3D %u group by folder_id
>>>>
>>>> SQLExecute returns OK
>>>> SQLNumResultCols returns 4 columns as expected
>>>>
>>>> the SQLDescribeColW blows up when calling with column #2,=20
>>>> corresponding
>>>> to sum(file_size). file_size is a bigint field. There are only 5
>>>> records, and the sum of the file_size is under 1MB. So shouldn't be=20
>>>> any
>>>> bigint overflow or something.
>>>>
>>>> I used to use a double precision and it worked fine, then I figured=20
>>>> out
>>>> how to store into a bigint field and now this happens every time I d=
o
>>>> this query if there are any records in the table. If there are no
>>>> records it's fine.
>>>>
>>>> Regards
>>>>
>>>> Adrien de Croy
>>>
>>>
>>
>>
>>
>>
>
>

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL whencalling SQLDescribeColW

(2010/11/10 13:04), Adrien de Croy wrote:
>
> Hi
>
> I have some helper classes to fetch fields from a record, a helper class
> to manage iteration through a result set.
>
> If I call my fetch helper function for some field ordinal it works fine
> the first time. If I call it again (without having called any method to
> change the current row in the result set) it fails on the same ordinal,
> but works on other ordinals.
>
> So, it looks to me like the fetch call is cleaning up the field data
> when you fetch,

If the helper function calls SQLGetData() for the column, yes.
SQLGetData() cleans up data which it returns to the caller and
returns SQL_NO_DATA when all data was returned to the caller.
You can divide into multiple SQLGetData() calls using this feature
when a column has a big data.

regards,
Hiroshi Inoue


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc